Electronic draft capture

ABSTRACT

A method for processing financial transactions includes transmitting an authorization request to a payment processing gateway server. The authorization request includes a supplemental header having a contract identification field that stores an identification of a contract between a merchant and a payment provider. A transaction response transmission is received from the payment processing gateway server in response to the authorization request. The transaction response transmission includes a transaction response header and a response data component. The transaction response header includes identification of a particular transaction to which the transaction response transmission is applicable. The response data component includes an indication that the contract is invalid. The indication that the contract is invalid is responded to by facilitating a rejection of the financial transaction.

CROSS REFERENCE TO RELATED APPLICATION

The present application is a continuation of and claims priority of U.S.patent application Ser. No. 10/620,293, filed Jul. 15, 2003, the contentof which is hereby incorporated by reference in its entirety.

BACKGROUND OF THE INVENTION

The present invention relates to processing financial transactionauthorization requests from merchants. More specifically, the presentinvention relates to a payment processing gateway for use in processingfinancial transaction authorization requests and a protocol accessingsuch a gateway.

In a retail transaction, a purchaser purchases a retail product from amerchant. Retail transactions have been used throughout much of humanhistory. Having evolved from a simple barter system, there has been anongoing trend to make such transactions more efficient and convenientfor the consumer and the merchant. As an alternative to barter, moneywas used to represent the value of items to allow more flexibility insuch transactions. Next, there was the realization that the moneyinvolved in the transaction did not need to be physically present at thetransaction time. For example, a debit ledger can be maintained by themerchant and used to record sales in which credit was extended to theconsumer. This allowed the consumer to pay for the goods at a futuredate. Checking systems are also employed in which a check is issuedallowing the recipient to draw on those funds from a bank.

Charge, debit cards, electronic checks and the like (“financial cards”)provide far more convenience to the consumer than the use of physicalchecks. Originally, copies of receipts from such financial cardtransactions were simply maintained by the merchant and periodicallyprocessed. Eventually real time authorization techniques were providedby financial card issuers. In such systems, a merchant is able to obtainan authorization from the financial card issuer prior to completion ofthe retail transaction. Various types of authorization can be used, forexample an authorization can be obtained through oral communication,such as through a telephone call. Authorizations can also be obtainedthrough digital communication techniques.

Presently, many retail locations employ point of sale (POS) devices inwhich a magnetic strip on a financial card is “swiped” through a cardreader. Data on a “smartcard” chip can also be read. The data can beread using a magnetic sensor, electrical contacts, a radio frequency(RF) connection, or through other techniques. The card reader or adevice connected to the reader, initiates a telephone call with anauthorization center. The authorization center is able to immediatelyauthorize or decline a particular transaction. The point of sale deviceinforms personnel at the retail location of the result of theauthorization request. If the transaction is questionable, the merchantcan be required to obtain further information for verifying the cardholding prior to providing authorization for the transaction. With theadvent of the Internet, such authorization procedures are moving awayfrom point to point telephone connections and are beginning to exploitthe connectivity that the Internet provides. In such transactions, adevice at the point of sale uses a secure communication technique, suchas a Secure Socket Layer (SSL), to communicate with a authorizationgateway. The gateway is capable of simultaneously communicating withpoint of sale devices from multiple merchants. The gateway contacts theappropriate financial institution regarding the authorization requestand relays the result of the authorization request back to theappropriate point of sale device through the Internet connection. Thereis an ongoing need to improve the performance and convenience of suchtransactions.

SUMMARY OF THE INVENTION

Embodiments of systems and methods for processing financial transactionsare disclosed herein. In one embodiment, an authorization request istransmitted to a payment processing gateway server. The authorizationrequest includes a supplemental header having a contract identificationfield that stores an identification of a contract between a merchant anda payment provider. A transaction response transmission is received fromthe payment processing gateway server in response to the authorizationrequest. The transaction response transmission includes a transactionresponse header and a response data component. The transaction responseheader includes identification of a particular transaction to which thetransaction response transmission is applicable. The response datacomponent includes an indication that the contract is invalid. Theindication that the contract is invalid is responded to by facilitatinga rejection of the financial transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified diagram showing a payment processing gatewaycoupling a point of sale device to financial institutions across publicand financial networks.

FIG. 2 is a block diagram showing the point of sale device of FIG. 1 ingreater detail.

FIG. 3 is a block diagram showing the payment processing gateway of FIG.1 in greater detail.

FIG. 4 is a block diagram of a general computing environment in whichembodiments of the present invention may be practiced.

FIG. 5 is a block diagram showing an authorization request data packet.

FIG. 6 is a block diagram showing an authorization response data packet.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The present invention provides a protocol and implementation to supportvarious forms of electronic fund transaction types. Examples ofelectronic fund transactions are those which are based upon creditcards, charge cards, debit cards, check verification, gift cards,coupons, etc. As used herein, these various types of electronic fundtransactions are referred to as “financial transactions” or “financialcards,” although a physical card is not required. Various transactiontypes are supported including the types “authorize”, “void”, “return”,“settle”, etc.

Point of sale (POS) terminals communicate directly over a public networksuch as the Internet, or through a retail server system which couples tothe public network, to a payment processing gateway server. The paymentprocessing gateway server provides a link between authorization requestsreceived from the public network and at least one financial network. Thefinancial network provides communications with at least one financialinstitution which is capable of authorizing the particular transaction.The financial network can be a private network or can be a secure linkover a public network.

FIG. 1 is a simplified block diagram of an electronic fund transactionprocessing system 10 in accordance with one example embodiment of thepresent invention. The transaction processing system 10 includes a pointof sale (POS) device 12 which couples to a public network 14, such asthe Internet. A payment processing gateway 16 couples to the publicnetwork 14 and is in communication with the point of sale device 12. Thepayment processing gateway 16 couples to at least one financial network18A, 18B . . . 18N. The financial network 18A-N can be a private networkor a secure communication link over a public network such as theInternet. At least one financial institution 20A, 20B . . . 20N couplesto each of the respective financial networks 18A, 18B . . . 18N. Anynumber of financial institutions 20A-N can couple to a single financialnetwork 18A-N.

The point of sale device 12 can be physically located at a retaillocation such as a retail store. The device 12 can comprise anindividual cash register, for example, or can be a retail server systemwhich is used to connect to multiple point of sale devices. Such aretail server system can provide additional functionality such asinventory control, theft prevention, etc. The retail server system canbe implemented in a separate server or in a peer-to-peer architecture.The retail location can include a local area network which couples tothe point of sale device 12. In some systems, wireless networks areprovided. In one aspect, the present invention reduces communicationoverhead on such networks.

FIG. 2 is a simplified block diagram of point of the sale device 12shown in FIG. 1 and which includes a user input/output 30. The userinput/output 30 can comprise, for example, a display, keyboard, a touchscreen, pointing device, card reader such as a magnetic card reader,RFID reader, magnetic stripe reader, smartcard reader, voice recognitiondevice or the like, weighing scale, or any of the various inputs andoutputs discussed below or known in the art. The input/output 30 couplesto a processor system 32 which includes a memory 34. Memory 34 is usedfor storing programming instructions as well as data. A networkinterface 36 is used to couple the processor system 32 to the publicnetwork 14 over a physical layer 38. User input/output 30 is used toinitiate a financial card authorization request by processor 32.Processor 32 formats the request in accordance with the appropriateprotocol format for transmission by network interface 36 over thephysical layer 38. The physical layer 38 can be any type of networkconnection. In addition, processor system 32 can perform other functionssuch as maintain inventory, perform cash register operations, provideinstructions to an operator, provide information or advertisements to aconsumer, etc.

FIG. 3 is a simplified block diagram of payment processing gateway 16.Gateway 16 includes a network interface 40 configured to couple to thepublic network 14 through physical layer 42. A processor system 44includes a memory 47 which contains programming instructions and data.Processor system 44 couples to public network 14 through interface 40and to financial networks 18A-N through a network interface 46. Networkinterface 46 couples to financial network 18A-N through physical layer48.

In operation, gateway 16 receives authorization requests from point ofsale device 12 over public network 14. The authorization requests areformatted in accordance with the appropriate transmission protocol fortransmission over financial network 18A-N to a respective financialinstitution 20A-N. When gateway 16 receives a response to anauthorization request from the appropriate financial institution20A-20N, the result is relayed back to the respective point of saledevice 12 through the public network 14. In accordance with onetransmission protocol, the response transmission is identified such thatthe point of sale device 12 is able to determine to which authorizationrequest the response message relates. However, such a transactionidentification is not required when a single authorization request issent over a synchronous connection, such as a single credit cardtransaction. In this case, the point of sale device 12 can wait for areturn value to an httpost, or wait on a dedication socket, as there areno other transactions which must be followed. However, if multipletransaction authorization requests are sent, either at the point of saledevice or through a retail server system, or if multiple transactionsare bundled into a single message, or for some other reason asynchronous responses are supported, such a transaction identificationcan be used.

As illustrated below in greater detail, processor system 44 can haveother inputs, outputs or configurations. The network interface 46 andphysical layer 48 can be in accordance with any appropriate standard orprotocol.

FIG. 4 illustrates an example of a suitable computing system environment100 on which the invention may be implemented. System environment 100can implement point of sale device 12 and/or payment processing gateway16. The devices, for example payment processing gateway 16, can beimplemented across multiple environments 100. The computing systemenvironment 100 is only one example of a suitable computing environmentand is not intended to suggest any limitation as to the scope of use orfunctionality of the invention. Neither should the computing environment100 be interpreted as having any dependency or requirement relating toany one or combination of components illustrated in the exemplaryoperating environment 100.

The invention can be implemented in numerous other general purpose orspecial purpose computing system environments or configurations.Examples of well-known computing systems, environments, and/orconfigurations that may be suitable for use with the invention include,but are not limited to, personal computers, server computers, hand-heldor laptop devices, multiprocessor systems, microprocessor-based systems,programmable consumer electronics, network PCs, minicomputers, mainframecomputers, telephony systems, dedicated custom hardware, distributedcomputing environments that include any of the above systems or devices,and the like.

The invention may be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, etc. that performparticular tasks or implement particular abstract data types. In someembodiments, the invention is designed to be practiced in distributedcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed computing environment, program modules are located in bothlocal and remote computer storage media including memory storagedevices.

With reference to FIG. 4, an exemplary system for implementing theinvention includes a one or more general-purpose computing devices inthe form of a computer 110. Components of computer 110 may include, butare not limited to, a processing unit 120, a system memory 130, and asystem bus 121 that couples various system components including thesystem memory to the processing unit 120. The system bus 121 may be anyof several types of bus structures including a memory bus or memorycontroller, a peripheral bus, and a local bus using any of a variety ofbus architectures. By way of example, and not limitation, sucharchitectures include Industry Standard Architecture (ISA) bus, MicroChannel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus also known as Mezzanine bus.

Computer 110 typically includes a variety of computer readable media.Computer readable media can be any available media that can be accessedby computer 110 and includes both volatile and nonvolatile media,removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media includes both volatileand nonvolatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by computer 110. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer readable media.

The system memory 130 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 131and random access memory (RAM) 132. A basic input/output system 133(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 110, such as during start-up, istypically stored in ROM 131. RAM 132 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 120. By way of example, and notlimitation, FIG. 3 illustrates operating system 134, applicationprograms 135, other program modules 136, and program data 137.

The computer 110 may also include other removable/non-removablevolatile/nonvolatile computer storage media. By way of example only,FIG. 4 illustrates a hard disk drive 141 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 151that reads from or writes to a removable, nonvolatile magnetic disk 152,and an optical disk drive 155 that reads from or writes to a removable,nonvolatile optical disk 156 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 141 is typically connectedto the system bus 121 through a non-removable memory interface such asinterface 140, and magnetic disk drive 151 and optical disk drive 155are typically connected to the system bus 121 by a removable memoryinterface, such as interface 150.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 4, provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 110. In FIG. 4, for example, hard disk drive 141 is illustratedas storing operating system 144, application programs 145, other programmodules 146, and program data 147. Note that these components can eitherbe the same as or different from operating system 134, applicationprograms 135, other program modules 136, and program data 137. Operatingsystem 144, application programs 145, other program modules 146, andprogram data 147 are given different numbers here to illustrate that, ata minimum, they are different copies.

A user may enter commands and information into the computer 110 throughinput devices such as a keyboard 162, a microphone 163, and a pointingdevice 161, such as a mouse, trackball or touch pad. Other input devices(not shown) may include a joystick, game pad, satellite dish, scanner,or the like. These and other input devices are often connected to theprocessing unit 120 through a user input interface 160 that is coupledto a system bus, but may be connected by other interface and busstructures, such as a parallel port, game port or a universal serial bus(USB). The system bus may be implemented using any appropriatetechniques. A monitor 191 or other type of display device is alsoconnected to the system bus 121 via an interface, such as a videointerface 190. In addition to the monitor, computers may also includeother peripheral output devices such as speakers 197, printer 196, poledisplays, modems, network interface cards, etc. which may be connectedthrough an output peripheral interface 195.

The computer 110 is operated in a networked environment using logicalconnections to one or more remote computers, such as a remote computer180. The remote computer 180 may be a personal computer, a hand-helddevice, a server, a router, a network PC, a peer device or other commonnetwork node, and typically includes many or all of the elementsdescribed above relative to the computer 110. The logical connectionsdepicted in FIG. 4 include a local area network (LAN) 171 and a widearea network (WAN) 173, but may also include other networks. Suchnetworking environments are commonplace in offices, enterprise-widecomputer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 110 is connectedto the LAN 171 through a network interface or adapter 170. The WANnetworking environment is provided by the public network 14 or privatenetworks 18A-N. The computer 110 typically includes a modem 172 networkinterface card, or other means for establishing communications over theWAN 173, such as the Internet. A network connection to the WAN may alsobe through a gateway, router, proxy, or other connection to the WAN overthe LAN. The modem 172, which may be internal or external, may beconnected to the system bus 121 via the user input interface 160, orother appropriate mechanism. In a networked environment, program modulesdepicted relative to the computer 110, or portions thereof, may bestored in the remote memory storage device. By way of example, and notlimitation, FIG. 4 illustrates remote application programs 185 asresiding on remote computer 180. It will be appreciated that the networkconnections shown are exemplary and other means of establishing acommunications link between the computers may be used.

In one aspect, the present invention provides a new protocol fortransmission of authorization requests and/or authorization responsesbetween point of sale device 12 and payment processing gateway 16 overpublic network 14. The protocol can be configured for optimizedimplementation with retail management software which operates on aretail server system running on the gateway 16. In some embodiments,data can be preconfigured or otherwise previously stored in a databasein memory 47 on the payment processing gateway 16 such that the datadoes not need to be retransmitted over the public network 14. Thisprovides increased security while reducing transmission overhead.

In one aspect, a supplemental header is pre-pended to the authorizationrequest “payload”. FIG. 5 is a block diagram showing an exampleauthorization request 200. Authorization request 200 includes atransaction specific data field 202, cache-key field 204 and a cacheabledata field 206. The supplemental header field 208 is shown pre-pended tothe authorization request 200 on top of the cacheable data 206. Thesupplemental header carries a small amount of data which is used as akey to index a database in payment processing gateway 16. One example ofsuch a field is one which identifies the financial contract(s) and termsof operation for a particular acquiring banks or financial networks andthe payment gateway provider. Such a “contract ID” field can be used bythe payment processing gateway 16 to access a small list of validcontract IDs. This accessing can be through a simple in-memory list oran in-memory hash table to improve performance. If a particulartransaction request arrives at the payment processing gateway 16 with aninvalid contract ID, the payment processing gateway 16 can reject theauthorization request because a valid contract is not properlyidentified for the particular merchant who sent the authorizationrequest 200. In another example, the contract ID can be used toreference a particular subset of a group of valid financial networks,for example, an issuing financial institution frequently used more thanone financial network and an acquiring bank or financial institutionwill indicate which subset of the various networks can be used by themerchant.

The rejection from the payment processing gateway 16 can be in the formof an authorization or transaction response transmission 230 shown inFIG. 6. A transaction response can include a transaction identificationheader field 232 and a response data field 234. The transactionidentification field 232 identifies a particular transaction to whichthe response 230 is applicable. For example, a merchant may issuemultiple transaction authorization requests 200 within a short period oftime and the transaction identification field 232 is used to match aparticular response with the appropriate request. As discussed above,the transaction ID is not required in all embodiments. The responsefield 234 includes data which indicates the response to theauthorization request 200 such as “authorized”, “declined”, “hold card”,“cut card”, “bad card”, “call issuer for further information”, orrequest additional information from the purchaser, for example, toverify the authenticity of the card holder. As discussed below, thegateway 16 can also request transmission of cacheable data to populate acache. If the contract ID for the supplemental header 208 is invalid,the payment processing gateway 16 can provide a response 234 to theauthorization request 200 which indicates that the contract is invalid.

The contract ID field can also be used to audit transactions by paymentprocessing gateway 16. This auditing can be used to ensure thatmerchants utilizing the payment processing gateway 16, or the financialinstitutions utilizing payment processing gateway 16, are properlycharged for the use of the service. Further, the contact ID field can beused to analyze transactions to determine the source of thetransactions, destination of the transaction, particular merchantsinvolved, particular terms of the contract, etc. In one specificexample, the contract identification comprises two bytes of 8 bits each.

In another example, the supplemental header 208 includes a payment typefield. The payment type field is used to provide information to thepayment processing gateway 16 as to which particular financial network18A-N should be used for authorizing the transaction. For example, aparticular financial network 18A-N may be for credit transactions of aparticular type of debit card, while another financial network 18A-N maybe for use with credit cards. Other financial networks may be directedto advance payment types such as gift cards, coupons, smart creditcards, “microcredits”, etc. “Microcredits” are directed to a creditformat in which small dollar amount transactions may be performedthrough credit in a cost effective manner. The payment type field canalso indicate the particular protocol used by the back-end financialnetwork 18A-N and often within payload of the transmission, i.e., thetransaction specific data 202.

The transaction authorization protocol 200 illustrated in FIG. 5 alsoprovides a cache-key field 204. The cache-key 204 can be used touniquely identify a particular shop or store submitting an authorizationrequest. Merchant data can also be cached, for example for merchantswith multiple stores. The payment processing gateway 16 can retrievecache data within memory 34 illustrated in FIG. 2 based upon thecache-key. The cache data can be merchant or store invariant datainformation described below in more detail. In one specific embodiment,the cache-key field 204 comprises a 128 bit data field. The data fieldcan be used to carry a GUID (Globally Unique Identifier). In anotherspecific example, 12 bytes of the 128 bits identifies a particularmerchant while the remaining 4 bytes identifies a particular store ofthat merchant.

The authorization request 200 may also contain cache-able data 206.Typical prior art financial transaction protocols are capable ofcarrying a fairly rich set of merchant data, including for example,merchant name (25 bytes), country (3 bytes), state (2 bytes), location(13 bytes), city code/zip code (3 bytes), merchant category (4 bytes),acquirer bin (6 bytes), time zone differential (3 bytes), merchantcategory code (4 bytes), extra field separators for ease of viewing (4bytes) and others. The total can be more than 66 bytes of data for themain authorization message in a T-format authorization request message(direct debit). Typically, all of this data must be transmitted witheach authorization request.

With the present invention, the transaction invariant data can be cachedin memory 34 of payment gateway 16. In typical prior art gateways, sucha cache would provide limited benefits due to server performancelimitations and the difficulty of maintaining state across multipleservers arranged in a cluster. For example, the state of a particulartransaction would be required to be maintained across a cluster ofservers in a performat manner because there is a relatively high volumeof authorization request which must be processed in near real time.Further, it is difficult to ensure that cached data is maintained orotherwise restored when a server is reset.

Web servers, for example, tend to be inherently stateless. With thepresent invention, payment processing gateway 16 is configured as a webserver offering a web service which maintains state using a cache asdesired in order to support such caching operations. The cache can bethrough any appropriate caching technique such as a shared file, adatabase, etc. Preferably, a caching mechanism is utilized whichprovides high performance and operates very efficiently to support largenumbers of simultaneous transactions. In one aspect, the merchantinvariant data is cached in volatile memory (i.e., RAM) of the paymentprocessing gateway 16. For example, by caching 100 bytes of data permerchant and with 200,000 merchants, 20 megabytes of memory world beutilized.

Although this caching operation is particularly useful for authorizationrequests, the caching can also be utilized with settlement requests. Asettlement request typically occurs less frequently than anauthorization request. In a settlement request, a number of transactionsare typically “batched” together for settlement with the appropriatefinancial institution. The settlement process involves the transfer offunds from the appropriate financial institution to the account of themerchant.

If the payment processing gateway 16 is implemented in a number ofdifferent servers, such as that provided by a web cluster, the cachingof merchant or transaction invariant data can be achieved in anyappropriate way. Even a small cluster of 2 servers can process arelatively large volume of authorization request traffic. For such acache to be effective, the state can be maintained for each transactionbeing serviced by the gateway 16. A state service can be maintainedacross multiple web servers in a web cluster. Such a state service canbe implemented in a shared server whereby each of the servers in the webcluster can access for the state information. Cache consistency andreplication across multiple servers must be maintained for such animplementation. One specific implementation of such a state service isthrough the .NET framework provided by Microsoft Corporation, ofRedmond, Wash. This framework supports a distributed computingenvironment in which applications may be written in any number of highlevel languages. The high level languages are compiled to a commonruntime language known as CLR (Common Language Runtime). Further, insuch an embodiment, the CLR can operate across various hardwareplatforms such that the implementation is hardware independent. In suchan embodiment, the payment processing gateway 16 consists of a number ofdistributed computing systems. Objects can be used to exchange databetween the systems and maintain.

In one implementation suitable for a small number of servers, eachserver maintains its own cache. A single server with sufficientprocessing capabilities may be capable of processing a substantialnumber of authorization requests.

The state service can operate with a database server, such as an SQLserver which can be used to provide backup of stored data. The databasecan be used to restore the in-memory cache upon system failure of otherfault.

In some embodiments, a single database access is employed for eachauthorization per transaction. For example, a procedure stored in thepayment processing gateway 16 can be used to log the transaction tomemory, for auditing, reporting, billing or other purposes. The sameprocedure used to log the data to the database can be used to read theassociated cached invariant merchant data back from the database.

A web server front end can also be utilized with payment processinggateway 16 which directs web requests from a particular IP (InternetProtocol) address to the same server within the cluster. This particularredirection can be set for any time period, for example a number ofdays. Such a front end can be implemented in software or hardwarecomponents. With such an implementation, it is not necessary tosynchronize the web server cache within the cluster. Instead, each webserver within the cluster provided by the payment processing gateway 16need only maintain state for the particular transactions which it ishandling.

For small scale applications, a web service can be utilized such as thatprovided by ASP.NET. A particular ASP.NET page can be provided on eachweb server within the web cluster and used to update the cache of agiven server.

A custom server can be provided which provides a state server to othercomputers within the cluster. The server can maintain an in-memory cacheof merchant or store invariant records. The state server can respond torequests from the web cluster. If the state server is reset or otherwiselooses data, the web cluster can provide a negative acknowledgement(i.e., NACK) to the merchant/store POS 12 thereby requesting that acomplete data transmission be provided with the next transmission. Thetransmission of the complete data set can be provided for a desiredlength of time. This will cause the merchant to provide all of themerchant invariant data such that the database provided by the gateway16 can be repopulated. During this period, the payment processinggateway 16 can provide the appropriate financial institution 20A-N withall the data received from a particular merchant, mapping various fieldsas required.

In embodiments such as those discussed above in which various data iscached within a memory in payment processing gateway 16, softwareoperating at the point of sale device 12 can be configured toperiodically transmit the entire data set for a given merchant to thepayment processing gateway. This can be used to allow webservers orstate servers of gateway 16 to be individually reset without difficulty.For example, the software running on a point of sale device 12 can beconfigured to submit a full data set every 2, 8 or 24 hours. Datatransmissions such as the authorization response 230 shown in FIG. 6 caninclude an additional data field to allow the payment processing gateway16 to indicate that the full merchant data is required. Alternatively, aseparate message can be sent by the gateway 16. This data can be sentindependently, or can be included in the next transaction request.Further, if only partial data is required, the message from the paymentprocessing gateway 16 to the point of sale device 12 can indicate whichdata field or fields must be re-sent. In such a configuration, thepayment processing gateway 16 can continue to accept partial data for aperiod of time after the initial request is sent. This allows multiplepoint of sale devices 12 within a store to transmit data to a paymentprocessing gateway 16 which is implemented across multiple servers.

In order to further reduce the overhead of the messages exchanged acrossthe public network 14, or local networks of the retail location, in oneaspect the present invention eliminates redundant or unrequiredtransmissions. For example, some acknowledgement messages used insocket-based protocols such as the protocol implemented by VisaNet areredundant. This is especially true for protocols based upon HTTPS. Inone specific example, the acknowledgement (ACK) which is transmittedbefore a response for a credit card transaction in a single transactionmode is not required. Although the acknowledgement can be useful inmonitoring operation of the software during debugging, it is notnormally required by the point of sale device 12. Other suchnon-essential transmissions can also be eliminated.

The various transmissions between the point of sale device 12 and thepayment processing gateway 16, including the authorization request 200and the authorization response 230, can be implemented using a number oftechniques. For example, the HTTPS protocol can be used in which apacket or partial packet for transmission on a financial network 18A-Nis “wrapped” as the payload in the secure transmission. Thisconfiguration is particularly useful when integrating point of saledevices 12 which are at retail locations or which are implemented onlinethrough a merchant website. Further, this configuration can scale tohigh transaction volumes as required.

In another example, the payment processing gateway 16 provides an XMLservice for communication with the point of sale device 12. Thisconfiguration is also well suited for integrating point of sale devices12 which exist at both retail locations and from online merchants.

A secure socket layer (SSL) protocol can be used in which a particularmessage or packet is carried in an SSL wrapper. This implementation maybe required for some debit card transactions and is suited for the highperformance required to handle a large volume of transactions. Further,such a protocol can be used to keep a socket open on a financial network18A-N during the entire transaction process. Server clusteringtechniques such as thread pooling, clustering and load balancing can beimplemented to support such an SSL protocol.

In another implementation of the present invention, the paymentprocessing gateway 16 can provide a back end server process to maintainopen payment sockets (or equivalents) through the financial networks18A-N. Such a back end service can be synchronized with a statelessfront end coupled to public network 14. Although credit cardauthorizations can typically be handled as a single synchronoustransaction, debit card transactions typically require an additionalfinal acknowledgement from the point of sale device 12 to the paymentprocessing gateway 16 and to the appropriate financial institution 20A-Nover a financial network 18A-N. This additional acknowledgement confirmsthat the retailer received the authorization acknowledgement and thatthe funds transfer was settled. If this acknowledgement is not received,the transaction is automatically reversed and the funds are returned tothe customer's account. This can be implemented using a socket basedprotocol, such as SSL, where a server thread is used to maintain boththe front end and back end socket sessions. However, this is moredifficult to implement in a web based protocol which utilizes webservers such as Microsoft's IIS. As discussed above, web services areinherently stateless. Therefore, without additional implementation, thefinal acknowledgement may go to a different thread than the originaltransaction, and possibly even to a different server in a web cluster.In one aspect, the present invention maintains a thread in the webservice such that such an acknowledgement can be sent to the appropriatefinancial institution.

The back end server process typically on a separate common server can beused to maintain an open back end socket over the appropriate financialnetwork 18A-N. In such an embodiment, the socket must be uniquelyidentified to the front end web server, for example using a GUID whichthe back end server maps to a specific socket port. The front end webserver coupled to the public network 14 will place transaction messageson the appropriate queue. The queue is then accessed by the back endserver process. The back end server process can be single ormulti-threaded and processes messages by assigning them to a new orexisting socket session as appropriate. A new socket session with afinancial institute 18A-N is opened at the start of each transaction andclosed at the end of the transaction. All messages for a giventransaction will occur over the same socket. Socket connections forincomplete transactions can be set to time out after a predeterminedinterval to protect server resources.

Although in typical payment processing systems, the point of sale deviceis required to provide an acknowledgement to the gateway during a debitcard transaction, in one aspect, the present invention operates withoutthe need for such a second acknowledgement. For example, the gateway cansend a second acknowledgement back through the financial network withoutwaiting for the acknowledgement to be received from the point of saledevice. This allows the transaction to be stateless within the gatewayand the debit transaction can then be easily supported over the HTTPSprotocol without the need to use sockets such as SSL, directly. Thisconfiguration allows standard web servers to implement the presentinvention. Without the second acknowledgement from the point of the saledevice, an additional safety mechanism can be provided to prevent aduplicate transaction from being processed. For example, the gateway candetect that the same or a similar transaction is being run from the sameterminal or store within a specific period of time. If such atransaction is identified by the gateway, the gateway can simply blockthe transaction or send some type of a message back to the point of saledevice indicating that an error has occurred or warning that a duplicatetransaction has been received, request a confirmation that the duplicatedata should be processed, request that the data be specifically calledin, or simply acknowledge a successfully processed transactionpreviously. For example, if the same payment instrument is used from thesame point of sale terminal within a relatively small time window, forexample, one to two minutes, a simple acknowledgement can be provided.

Although the present invention has been described with reference toparticular embodiments, workers skilled in the art will recognize thatchanges may be made in form and detail without departing from the spiritand scope of the invention. In one aspect, the present invention isconfigured to operate as a web service. In another aspect, a socketserver implementation is used. In general, web services providetransactional functions which operate across a network such as theInternet. Web services adhere to a shared specification such that theyare able to share objects and exchange data. One extension of webservices which is well suited for implementation of the presentinvention is the web services enhancements (WSE) class library availablein the Microsoft.NET framework. The present invention is applicable toelectronic fund transfers based upon financial transaction authorizationrequests, and response to such requests. Although cards are specificallydiscussed, the invention relates to any type of payment instrument thatcan be used. The financial transaction authorization request areconveyed from a source, such as a store or merchant, to an authorizationprovider, such as a financial institution, over public and/or privatenetworks or direct connections.

1. A method of authorizing a financial transaction, the methodcomprising: receiving a first authorization request from a point of saledevice, the first authorization request including a first transactionspecific data field, a first cache key field, a first cacheable datafield, and a first supplemental header field, the first cacheable datafield including merchant data, the first supplemental header including afirst contract ID field that is used as a key to index a database and apayment type field that is used to identify a particular financialnetwork; accessing a list of valid contract IDs utilizing the firstcontract ID field; uniquely identifying a particular store submittingthe first authorization request utilizing the first cache key field;caching the merchant data in a volatile memory component of a paymentprocessing gateway; sending a first authorization transmission inresponse to the first authorization request, the first authorizationtransmission including a transaction identification field and a responsedata field, the transaction identification field identifying aparticular financial transaction to which the first authorizationtransmission is applicable, the response field indicating a response tothe first authorization request, wherein the response is selected fromthe group consisting of “authorized,” “declined,” “hold card,” “cutcard,” “bad card,” “call issuer for further information,” and “requestadditional information from the purchaser”; receiving a secondauthorization request from the point of sale device, the secondauthorization request including a second transaction specific data fieldand a second cache key field; and retrieving the merchant data from thevolatile memory component utilizing the second cache key field.
 2. Themethod of claim 1 wherein the first supplemental header identifies afinancial contract and terms of operation for a particular acquiringbank and a payment gateway provider.
 3. The method of claim 2 whereinthe point of sale device is a retail server system that is used toconnect multiple point of sale devices.
 4. The method of claim 3 furthercomprising the retail server system providing inventory control andtheft protection.
 5. The method of claim 4 wherein accessing a list ofvalid contract IDs comprises accessing an in-memory hash table.
 6. Themethod of claim 5 wherein the first authorization transmission includesa request for the point of sale device to transmit cacheable data topopulate a cache.
 7. The method of claim 6 further comprising: auditingfinancial transaction processed by a payment process gateway utilizingthe first contract ID field; and utilizing the audit to ensure thatmerchants using the payment process gateway are properly charged.
 8. Themethod of claim 7 wherein the merchant data comprises a merchant name, acountry, a state, a location, a city code/zip code, a merchant category,an acquirer bin, a time zone differential, a merchant category code, andan extra field separator.
 9. A method of processing a financialtransaction, the method comprising: transmitting an authorizationrequest to a payment processing gateway server, the authorizationrequest including a supplemental header that includes a contractidentification field that stores an identification of a contract betweena merchant and a payment provider; receiving, from the paymentprocessing gateway server in response to the authorization request, atransaction response transmission, wherein the transaction responsetransmission includes a transaction response header and a response datacomponent, the transaction response header including identification of aparticular transaction to which the transaction response transmission isapplicable, and wherein the response data component includes anindication that said contract is invalid; and responding to theindication that the contract is invalid by facilitating a rejection ofthe financial transaction.
 10. The method of claim 9, wherein theauthorization request further comprises a transaction specific datafield that includes an indication of the identification of theparticular transaction.
 11. The method of claim 10, wherein theauthorization request further comprises a cache key field thatidentifies a particular business sub-unit for which data is to be cachedseparately from a different business sub-unit.
 12. The method of claim10, wherein the authorization request further comprises a cache keyfield that includes an identifier that points to a particular datastorage location on the payment processing gateway server.
 12. Themethod of claim 10, wherein the authorization request further comprisesa cache key field that includes an identifier that points to aparticular one of a plurality of data storage locations maintained onthe payment processing gateway server for the merchant.
 13. A method ofprocessing a financial transaction, the method comprising: transmittingan authorization request to a payment processing gateway server, theauthorization request including a mechanism for identifying a specificone of a plurality of data storage locations maintained on the paymentprocessing gateway server for a particular merchant; and receiving, fromthe payment processing gateway server in response to the authorizationrequest, a transaction response transmission, wherein the transactionresponse transmission includes a transaction response header and aresponse data component, the transaction response header includingidentification of a particular transaction to which the transactionresponse transmission is applicable, and wherein the response datacomponent includes an indication that said contract is valid orotherwise authorized.
 14. The method of claim 13, wherein the mechanismfor identifying a specific one of a plurality of data storage locationsis a mechanism for identifying a particular business sub-unit for theparticular merchant.
 15. The method of claim 13, wherein the mechanismfor identifying a specific one of a plurality of data storage locationsis a mechanism for identifying a particular business unit.
 16. Themethod of claim 13, wherein the mechanism for identifying a specific oneof a plurality of data storage locations is a mechanism for identifyinga particular store.
 17. The method of claim 13, wherein the mechanismfor identifying a specific one of a plurality of data storage locationsis a mechanism for identifying a shared data stored location madeaccessible as part of a web service.
 18. The method of claim 13, whereinthe mechanism for identifying a specific one of a plurality of datastorage locations is a mechanism for identifying a data stored locationthat is configured to support simultaneous data recordationtransactions.
 19. The method of claim 13, wherein the mechanism foridentifying a specific one of a plurality of data storage locations is amechanism for identifying a volatile data storage memory.
 20. The methodof claim 13, wherein the mechanism for identifying a specific one of aplurality of data storage locations is a mechanism for identifying adata storage location in which there is a collection of pre-existingtransaction data for the merchant already cached.